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Status of the Claims 

• Claims 1-8 are pending in the Application after entry of this amendment. 

• Claims 1-8 are rejected by Examiner. 

• No amendments are made to the claims. 

Summary of Telephone Interview 

Applicant's representative would like to thank the Examiner for the courtesy 
extended during the telephone interview on April 20, 2011. Prior to the telephone 
interview, Applicant's representative provided a set of proposed remarks distinguishing 
the present claimed invention from the cited art. During the telephone interview, the 
Examiner indicated that he reviewed these remarks and that these remarks appear to 
overcome the cited art of record (Carpenter and Templin). It was agreed that the formal 
response to the outstanding Office Action include the discussed remarks. The Examiner 
also indicated that he wished to undertake a further review of Applicant's remarks to 
confirm his belief that the present claimed invention is patentable over Carpenter and 
Templin and perform a further search, if needed. It was agreed that a call would be 
placed to Applicant's representative to discuss a possible quick resolution to any issue 
arising from a further review of the pending claims. Applicant's representative would 
welcome the opportunity to discuss the present application with the Examiner to further 
the advancement of prosecution. 

Claim Rejections Pursuant to 35 U.S.C. §103(a) 

Claims 1-8 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
B. Carpenter, et al. Connection of IPv6 Domains via IPv4 Clouds (Network Working 
Group), hereafter referred to as "Carpenter" in view of US Patent Application 
Publication No. 2001/0040895 to Templin. Applicants respectfully traverse the 
rejection. 
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The failure of an asserted combination to teach or suggest each and every 
feature of a claim remains fatal to an obviousness rejection under 35 U.S.C. § 103. 
Section 2143.03 of the MPEP requires the "consideration" of every claim feature in an 
obviousness determination. To render a claim unpatentable, however, the Office must 
do more than merely "consider" each and every feature for this claim. Instead, the 
asserted combination of the patents must also teach or suggest each and every claim 
feature. See In re Royka, 490 F.2d 981, 180 USPQ 580 (CCPA 1974) (emphasis added) 
(to establish prima facie obviousness of a claimed invention, all the claim features must 
be taught or suggested by the prior art). Indeed, as the Board of Patent Appeals and 
Interferences has confirmed, a proper obviousness determination requires that an 
Examiner make "a searching comparison of the claimed invention - including all its 
limitations - with the teaching of the prior art." See In re Wada and Murphy, Appeal 
2007-3733, citing In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis in 
original). "If an independent claim is nonobvious under 35 U.S.C. 103, then any claim 
depending therefrom is nonobvious" (MPEP §2143.03, citing In re Fine, 837 F.2d 
1071, 5 USPQ2d 1596 (Fed. Cir. 1988)). 

Independent Claim 1 provides a method for supporting a 6to4 tunneling 
protocol across a network address translation mechanism. The method includes 
receiving, from a first host located on a first network, an outbound IPv6 packet 
encapsulated into an IPv4 packet. The IPv4 packet comprises an IPv4 header with a 
private IPv4 source address of the first host. The outbound IPv6 packet comprises an 
IPv6 header with a 6to4 source address and the IPv6 header comprising an Interface ID 
value. The private IPv4 source address in the IPv4 header is translated into a public 
IPv4 source address. The translated packet is transmitted over an IPv4 network to a 
remote host. The method further comprises storing an association of the private IPv4 
source address and the Interface ID value of the 6to4 source address for opposite 
address translation of inbound packets returned by the remote host. For the reasons 
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presented below, it is respectfully submitted that Carpenter alone or in combination 
with Templin, fail to teach or suggest each feature of the present claimed arrangement. 

Carpenter describes the mechanism by which IPv6 domains may communicate 
with one another via an IPv4 cloud network. The Rejection relies on various sections of 
this standard in support of the assertion that the present claimed arrangement is 
partially disclosed. Applicant respectfully disagrees. 

On page 4 of the Rejection, the Office Action asserts that page 4, paragraph 1.1 
and page 5, paragraph 2 teaches the present claimed feature of "receiving from a first 
host located on a first network an outbound IPv6 packet encapsulated into an IPv4 
packet, the IPv4 packet comprising a IPv4 header with a private IPv4 source address of 
the first host, the outbound IPv6 packet comprising a IPv6 header with a 6to4 source 
address, the IPv6 header comprising an Interface ID value". Applicant respectfully 
disagrees. Applicant respectfully submits that the Rejection mischaracterizes the cited 
sections of Carpenter. While Carpenter does describe encapsulating an IPv6 packet in 
an IPv4 packet, Carpenter fails to teach or suggest the present claimed packet structure. 
Contrary to the assertion in the Rejection, Carpenter fails to teach or suggest "the IPv4 
packet comprising a IPv4 header with a private IPv4 source address of the first 
host" as in the present claimed arrangement. In fact, Carpenter teaches away from this 
feature because on page 4, paragraph 2 entitled IPv6 Prefix Allocation it states that 

"a subscriber site has at least one valid, globally unique 32- 
bit IPv4 address, referred to in this document as V4ADDR. 
This address MUST be duly allocated to the site by an 
address registry (possibly via a service provider) and it 
MUST NOT be a private address [RFC 1918]" 

Furthermore, on page 5, paragraph 3, entitled "Encapsulation in IPv4" states on line 1 1 
that 
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"The IPv4 header contains the Destination and Source IPv4 
addresses. One or both of these will be identical to the 
V4ADDR field of an IPv6 prefix formed as specified 
above". 

Therefore, Carpenter unambiguously states that the IPv4 header cannot include a 
private IPv4 address as in the present claimed arrangement. 

Additionally, the Rejection relies on page 5, paragraph 2 in support of the 
assertion that Carpenter teaches or suggests the present claimed feature of "the 
outbound IPv6 packet comprising an IPv6 header with a 6to4 source address, the IPv6 
header comprising an Interface ID value". Applicant respectfully disagrees and asserts 
that this too is a mischaracterization of the teachings of Carpenter. The Rejection 
asserts that the SLA ID is the 6to4 source address and that Interface ID, together, 
comprise the claimed IPv6 header. Applicant respectfully disagrees. The SLA ID is 
NOT a 6to4 source address. Rather, as is well known to those skilled in the art, the 
SLA ID is a particular field in either a native IPv6 header or within a 6to4 address (see 
Carpenter page 3 which clearly defines a "6to4 address as "an IPv6 address constructed 
using a 6to4 prefix". The SLA ID is NOT part of the prefix and, more specifically, the 
SLA ID is a value associated with a site level aggregator ID (see Fig. 2 of the present 
specification and corresponding description thereof). Moreover, it is well known that 
the SLA ID merely refers to the subnet addresses contained within a particular domain 
and therefore are a piece of information that is included in a 6to4 source address but is 
NOT the entire source address as asserted in the Rejection. Thus, the structure of the 
claimed IPv6 header which includes "a 6to4source address" and "an Interface ID" is 
neither taught nor suggested by Carpenter. 

Furthermore, the Rejection erroneously relies on page 4, paragraph 1.1, line 13 
and page 5, paragraph 2 in support of the assertion that the claimed feature of 
"translating the private IPv4 source address in the IPv4 header into a public IPv4 
source address". Specifically, the Rejection equates the "V4ADDR" value as the 
private address and the "6to4 address" as the public address. It is respectfully submitted 
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that this is a mischaracterization of these elements in Carpenter which do not function 
in the manner asserted in the Rejection. The assertion in the Rejection teaches against 
the disclosure provided by Carpenter. Specifically, on page 4, paragraph 2 (quoted 
above) V4ADDR is a globally unique IPv4 address enabling the domain to be located 
on a communications network. Therefore, contrary to the characterization in the 
Rejection, V4ADDR CANNOT be "a private IPv4 address". Rather, V4ADDR is a 
globally unique and public address and it is NOT translated into a 6to4 address as 
asserted in the Rejection. Rather, a 6to4 address is an IPv6 address that is formed 
including a specific 6to4 address prefix that enables encapsulation within an IPv4 
packet for transport over an IPv4 network. Moreover, there is nothing in the sections of 
Carpenter relied on in the Rejection that discloses or suggests "translating the private 
IPv4 source address in the IPv4 header into a public IPv4 source address". 

The Rejection concedes that Carpenter fails to teach or suggest "storing an 
association of the private IPv4 source address and the Interface ID value of the 6to4 
source address for opposite address translation of inbound packets returned by the 
remote host" as recited in claim 1. However, the Office Action asserts that Templin in 
paragraph 255, lines 1 - 6 discloses this feature. Applicants respectfully disagree. 

Templin describes a system facilitating IPv6-IPv4 compatibility wherein IPv6 
islands are present in heterogeneous IPv4/IPv6 networks (see para. [0005]). In order to 
accomplish this, Templin seeks to provide an IPv6-IPv4 compatibility aggregatable 
global unicast address format that reduces complexity for migrating from IPv4 
networks to IPv6 networks (see para. [0006]). Unlike the claimed arrangement, 
Templin seeks to provide a fundamentally different standard than the one described in 
Carpenter. Templin continues in paragraph [0007] to define the structure of the IPv6- 
IPv4 compatibility address as 



"A globally aggregatable IPv6 address prefix is associated 
with an IPv4 node having an IPv4 address and deployed in 
the network. The IPv4 node is configured with an IPv6- 
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IPv4 compatibility address that includes a prefix portion 
and an interface identifier portion. The prefix portion 
contains the IPv6 address prefix associated with the IPv4 
node and the interface identifier portion contains the IPv4 
address. Packets addressed to the IPv6-IPv4 compatibility 
address of the IPv4 node are routed across IPv6 
infrastructure using the IPv6 prefix portion or tunneled 
across IPv4 infrastructure using the IPv4 address embedded 
in the interface identifier portion" 

Thus, the addressing format in Templin is fundamentally different from the 
present claimed arrangement because Templin fails to teach or suggest an IPv6 packet 
encapsulated in an IPv4 packet wherein the header of the IPv6 packet includes a 6to4 
source address and an Interface ID. Unlike the present claimed arrangement, the 
address format of Templin includes an IPv6 prefix and an IPv4 Address embedded in 
the identifier. This is not equivalent an IPv4 packet including an IPv4 Header having a 
private IPv4 address and an IPv6 packet encapsulated in the IPv4 packet that includes a 
6to4 source address AND an Interface ID. The IPv6-IPv4 compatibility address 
described in Templin is not equivalent to a "6to4 source address" that is included in the 
IPv6 header in the present claimed arrangement. The present claimed method 
advantageously uses 6to4 source addresses to facilitate communication between IPv6 
sites or native IPv6 networks over an IPv4 network without explicit tunnel setup 
(Specification, page 2, lines 18 - 22). Templin fails to teach or suggest the use of 6to4 
source addresses within an IPv6 header and instead uses a compatibility address format 
that is not equivalent to the present claimed arrangement. 

The Rejection relies on paragraph [0255] of Templin in support of the assertion 
that Templin teaches 'storing an association of the private IPv4 source address and the 
Interface ID value of the 6to4 source address for opposite address translation of 
inbound packets returned by the remote host". Applicant respectfully disagrees. While 
the cited section describes a type of reverse translation, the mechanism by which the 
translation in Templin is performed is fundamentally different from the present claimed 
arrangement. Unlike the present claimed arrangement, Templin, in [0251] transforms 
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the IPv6-IPv4 compatibility address interface identifier 304 with an embedded IPv4 
address of the sending node into an anonymous ID for interdomain routing outside the 
subnet 10. Thus, the translation performed by Templin is done to "enforce policy of not 
exposing internal IPv4 addresses to outside of the subnet." Unlike the claimed 
arrangement Templin maintains a mapping identifier to the actual IPv4 address of the 
IPv4 node and that this identifier is not vulnerable to eavesdropping. Therefore the 
mapping in Templin is performed using data values that are fundamentally different 
from and not equivalent to the present claimed arrangement. Merely discussing a form 
of reverse network translation cannot teach or suggest the present claimed feature of 
"storing an association of the private IPv4 source address and the Interface ID value of 
the 6to4 source address for opposite address translation of inbound packets returned by 
the remote host". 

The Office Action asserts it would be obvious to combine the features of 
Templin with the system of Carpenter to allow devices on an IPv6 network to send 
packets to and receive packets from devices on an IPv4 network. Applicants 
respectfully disagree for the reasons previously submitted in the response filed October 
21, 2010 and which are incorporated herein by reference. Specifically, Templin 
describes a competing and different compatibility address format than the one 
described in Carpenter. Moreover, Applicant respectfully submits that it would not be 
obvious to modify Carpenter in the manner suggested to produce the present claimed 
arrangement because Carpenter specifically notes on page 6, paragraph 3.1 that 

"The link-local address of a 6to4 pseudo-interface 
performing 6to4 encapsulation would, if needed, be formed 
as described in Section 3.7 of [MECH]. However, no 
scenario is known in which such an address would be 
useful, since a peer 6to4 gateway cannot determine the 
appropriate link-layer (IPv4) address to send to." 

The link-local address is the Interface ID of the present claimed arrangement 
which is used as part of the mapping table to perform the opposite translation. Thus, it 
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would not be obvious to modify Carpenter to include the feature of "storing an 
association of the private IPv4 source address and the Interface ID value of the 6to4 
source address for opposite address translation of inbound packets returned by the 
remote host" as in the present claimed arrangement because, in Carpenter's own words, 
there was no anticipated use of the value in the Interface ID such as claimed in the 
present claimed arrangement. 

Furthermore, in response to these arguments, the rejection on page 3 asserts that 
it is compatible because Templin is relied upon for the single feature of reverse 
translation. However, as discussed above, the type of reverse translation in Templin is 
fundamentally different from the present claimed feature of "storing an association of 
the private IPv4 source address and the Interface ID value of the 6to4 source address 
for opposite address translation of inbound packets returned by the remote host". Thus, 
even if one could combine the address formats in Carpenter and Templin, the type of 
reverse translation would result an anonymous identifier being included in a packet 
transmitted over a network and translating the anonymous identifier to find the 
corresponding actual IPv4 address. This is fundamentally different from the present 
claimed arrangement creates a map that uses the private IPv4 address in the IPv4 
header and the Interface ID of the IPv6 header that is encapsulated in the IPv4 packet. 
These features are not taught nor suggested by Carpenter alone or in combination with 
Templin. 

Claims 2 - 6 are dependent on claim 1 and are considered patentable for the 
reasons presented above with respect to claim 1 per MPEP §2143.03. Therefore, it is 
respectfully submitted that Carpenter (with Templin) fail to teach or suggest the 
features of claims 2-6. Consequently, withdrawal of the rejection of claims 2 - 6 is 
respectfully submitted. 

Independent claim 7 includes similar features as those described above with 
respect to claim 1 . Therefore, Applicants respectfully submit that independent claim 7 
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is patentable for the reasons presented above with respect to claim 1. Specifically, 
Carpenter (with Templin) fail to teach or suggest "an application for storing, for each 
outbound packet received from a host of an IPv6 network, the private IPv4 addresses 
and an Interface ID value included in a 6to4 source address of a host; and for updating 
a 6to4 destination address of an inbound packet with a stored private IPv4 address 
having same Interface ID as the 6to4 destination address" as recited in claim 7. 
Therefore, withdrawal of the rejection of claim 7 is respectfully requested. 

Claim 8 is dependent on claim 7 and is considered patentable for the reasons 
presented above with respect to claim 7per MPEP §2143.03. Therefore, it is 
respectfully submitted that Carpenter (with Templin) fail to teach or suggest the 
features of claim 8. Consequently, withdrawal of the rejection of claim 8 is respectfully 
submitted. 

It is respectfully submitted that the Office Action fails to make a prima facie 
case that the present claimed arrangement of elements and claims is obvious over 
Carpenter alone or in combination with Templin. Therefore, as the combination fails to 
teach or suggest each feature claimed in claims 1 - 8, it is respectfully submitted that 
this rejection is overcome and should be reconsidered and withdrawn. 
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Conclusion 

Applicant respectfully submits that the pending claims are patentable over the 
cited art and respectfully requests reconsideration, and withdrawal of the 35 U.S.C. 
§103 rejections of the pending claims. 

Having fully addressed the Examiner's rejections, it is believed that, in view of 
the preceding remarks, this application stands in condition for allowance. Accordingly 
then, reconsideration for a Notice of Allowance is respectfully requested. 

The Examiner is authorized to charge Deposit Account No. 07-0832 for fees 
associated with this submittal. 



Respectfully submitted, 
Dirk Van Aken et al. 



Date: April 20, 2011 



/Jerome G. Schaefer/ 



Jerome G. Schaefer 
Attorney for Applicant 
Registration No. 50,800 
(609) 734-6451 
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